An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hello, My app "Kada: Learn Baybayin" (Apple ID: 6802533511) has been stuck in "Waiting for Review" status since August 19, with no transition to "In Review" as of today. This is the initial submission for version 1.0. Could someone confirm whether this is proceeding normally, or if there's anything needed from my side? Thank you for your time.

Hi - my app has been "Waiting for Review" for a week now (app id 6764576255). My past experience has been that my apps are normally reviewed within a couple of days. Is this waiting period normal at the moment?

App: AI RunCoach — App ID 6782097197, bundle ID com.airuncoach.app, Team ID 4N3X74Y2LF When adding a new build to our External Testing group, TestFlight shows: "Before you can use TestFlight to distribute beta builds of your app, you must renew your Apple Developer Program membership." Our membership is not expired: the Membership Details page shows renewal date 20 June 2027, auto-renew ON, and the €99 fee already paid. We've also checked Agreements, Tax, and Banking — nothing shows as pending or requiring action anywhere. In the meantime, our app has been stuck in "In Review" status since August 3, and TestFlight installations also seem to be blocked. A request for an expedited review produced no result, and a request for a phone consultation did not lead to any contact either. Did anyone else experience this, and could someone advise on how to contact Apple about this? Thanks in advance for any pointers.

Hello, I am investigating an intermittent In-App Purchase failure that occurred during App Review for the first release of my app. Environment Review device: iPad Air 11-inch (M3) OS: iPadOS 26.6 Environment: App Review sandbox Product type: Consumable StoreKit integration: RevenueCat through react-native-purchases 10.4.3 Observed behavior StoreKit successfully returned the products, localized names, and prices. The reviewer could see the credit packs and initiate the native purchase flow. My diagnostics show this sequence: Purchase initiated PURCHASE_CANCELLED; no transaction evidence Purchase initiated again RevenueCat code 2: STORE_PROBLEM elapsed: 9.4 seconds no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE elapsed: 0.6 seconds no transaction evidence code-block The relevant sanitized logs are: { "occurredAt": "2026-08-25T12:52:59.733Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "2", "providerReadableCode": "STORE_PROBLEM", "transactionEvidence": false, "elapsedMs": 9417 } code-block { "occurredAt": "2026-08-25T12:55:42.752Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "5", "providerReadableCode": "PRODUCT_NOT_AVAILABLE_FOR_PURCHASE", "transactionEvidence": false, "elapsedMs": 637 } code-block No App Store transaction was created, and therefore RevenueCat received no transaction or webhook for these attempts. Configuration verified I confirmed that: The affected product and the other consumable products are attached to the App Review submission. Product IDs match between the app, App Store Connect, and RevenueCat. Prices and localizations are configured. The products are available in the relevant storefronts. The Paid Apps Agreement is active. Banking and tax information are active. The In-App Purchase capability is present. The distribution build does not use a local StoreKit configuration file. The same build and affected product completed successfully afterward on a physical device using Apple Sandbox. The native purchase sheet opened, the transaction completed, and the consumable content was delivered successfully in my reproduction. The product metadata clearly remained available because its localized name and price were displayed. However, after the initial STORE_PROBLEM, subsequent purchase requests were rejected almost immediately as PRODUCT_NOT_AVAILABLE_FOR_PURCHASE. I do not have the underlying Apple NSError, such as an ASDServerErrorDomain or AMSErrorDomain value, because it was not exposed in my remote diagnostic record. Questions Can a failed sandbox transaction leave the StoreKit account/session or commerce-catalog state temporarily inconsistent, causing subsequent requests for an otherwise loaded product to return storeProductNotAvailable? Does StoreKit use separate metadata and transaction-eligibility services, allowing product information to load while the same product is rejected during purchase()? Are there known sandbox or StoreKit issues on iPadOS 26.6 that could produce this sequence? Could a stale App Review sandbox account token or storefront session explain the transition from STORE_PROBLEM to PRODUCT_NOT_AVAILABLE_FOR_PURCHASE? Is there any developer-side configuration that could explain this when the same product and binary complete successfully using another sandbox session? What additional logging should I capture from RevenueCat’s React Native SDK to preserve the complete underlying Apple error chain?

We are looking for guidance on a new app submission that has not moved from "Waiting for Review". Our first submission was rejected under Guideline 5.1.1(ii). We addressed the issue the same day by updating the purpose strings to clearly describe how the requested data is used, and resubmitted immediately. The status has not changed since. Why this is time-critical: the backend service our current users depend on is being shut down by our provider on August 28, 2026. The submitted app migrates to a new provider and is the continuation of that service. Without it, our existing users will be left without a working app. What we have already tried: Submitted an expedited review request on August 23, 2026 - no response Contacted Apple through the Contact Us module several times since then - no response beyond the automated acknowledgment each time We are not asking to skip the queue for convenience. We simply need to know whether the submission is progressing normally or whether something additional is required from us. We are ready to respond to any questions from App Review immediately, at any hour. Thank you.

Hi, I submitted the first version (1.0) of my iOS app for App Review on August 21, 2026, and it has now been almost 4 days. The submission is still showing “Waiting for Review” and has never changed to “In Review.” There are no messages in the Resolution Center, and I haven’t received any requests for additional information. I understand that review times can vary, especially for a first release, but I was wondering whether anyone else who submitted around August 21 is currently experiencing unusually long waiting times before the review actually starts. Is waiting 4+ days in “Waiting for Review” currently considered normal, or would it be appropriate to contact App Review Support at this point? Thanks!

Anyone with the similar experience? Would appreciate the advice: Timeline: Initial submission: ~4 weeks ago First review: Completed after ~2 weeks after we have sent the expedited review request Fixes applied: Completed within 24 hours Resubmission: August 12, 2026 Current status: Still in review - no activity for ~2 weeks We have a planned launch date that's now at risk due to this review delay. The lack of any reviewer interaction on the resubmission is particularly concerning. Any insights or advice would be greatly appreciated

Hello, 【Apple ID：6766467422，Chattoon: Voice Comic Diary】 Our app has been stuck in "In Review" status for 23 days now, and we would really appreciate any guidance or help from an Apple representative who might see this thread. Timeline: Aug 3, 2026: Submitted iOS version 1.3.0 (bug-fix-only update, no new features or permission changes) Submission ID: 993d767d-7020-454b-bf78-457bc8d8dcb7 Aug 11, 2026: Requested expedited review — request was accepted, confirmation email received (Case ID: 20000133567861) Since then: No status change. Still showing "In Review" Resolution Center: No messages, no requests for additional information Follow-up emails sent on Aug 10, Aug 13, and again this week — no response received to any of them This is a bug-fix update for our existing app (Chattoon: Voice Comic Diary), and the extended delay is now affecting our release plans. Has anyone else experienced something similar recently? Any advice on next steps, or could someone from the App Review team help check on the status of this submission? Thank you for your time.

Hello, since July 31st, our app has been stuck in the waiting for review state for a long period of time. We have already taken some actions. July 31: first submission. August 10: after waiting for over a week, we assumed there was a problem with the review queue -> cancel and resubmit. We attempted to submit an expedited request, but there was an issue with Apple service. It keeps saying "Sorry, we didn't receive your request." August 13: request a call with the Support Team. There was a guy named Tony who answered. Unfortunately, even Apple's staff is unable to access their internal system, as he told us that, and "he don't know why"? August 14: request a call again. Apple staff - Andy took up the phone and said he could not do anything about this situation and said... We just have to wait. August 25: rejected the build, upgraded the version, and submitted once more. We're hoping that this build will get out of the stucked queue... Side notes: Attempted to submit another expedited request were unsuccessful, the problem remained, tried several times. Made an appointment for a App Review team. But even the registration is still pending. Does anyone here have suggestions or solutions for this situation? This is the first time we've encountered this situation, and it's quite strange. Isn't that a side effect of the August 8th maintenance?

Hi everyone! I'm back again! 😄 A few months ago I posted here after submitting my first iOS app, after previously publishing it on Google Play. That experience was really helpful, so I'm hoping to get some advice from the community again. I've just submitted my new app, Vaqui, and it's currently Waiting for Review. Vaqui is an expense-sharing app for groups, mainly designed for trips. For example, three friends travel together and pay for different things: Pepe pays for the hotel. Sandra pays for groceries. Marcos pays for dinner. Everyone participates in different expenses. Vaqui calculates the resulting balances and suggests who should transfer money to whom. The app supports multiple currencies and stores the exchange rate used when an expense is recorded. The important part is that Vaqui does not process or hold money. It doesn't provide a wallet, banking account, payment processing, cards, or financial transactions. If someone owes another person money, Vaqui simply tells them something like: "Marcos owes Sandra $15,000." They make the actual transfer themselves using their bank or payment provider, outside Vaqui. The users can then mark the payment as made/received inside the app so the group knows what has already been settled. This made me wonder about something before the review starts: Would an app like Vaqui normally be considered a financial-services app by App Review, simply because it calculates debts/balances between users? Or is it generally treated as an expense-management / expense-sharing utility as long as it doesn't actually process, hold, or transfer money? I'm asking because I want to make sure I've understood the relevant App Review guidelines correctly rather than discovering during review that I've misunderstood something obvious. 😅 The current App Store Connect information is: App: Vaqui Bundle ID: mobi.todoapp.vaqui Apple ID: 6802352647 Status: Waiting for Review Platform: iOS / Flutter If anyone has submitted an app with similar functionality, I'd really appreciate hearing about your experience. Thanks! Greetings from Córdoba, Argentina 🇦🇷 And yes... once again I'm waiting for that little "In Review" notification. 🤞😂

Update: received a response, but it appears to misapply Guideline 3.1.1, looking for input Following up on my earlier post about a stuck submission (Submission ID: 1522a8de-defd-44f8-92e8-9edbb0d85c28). After a week of silence, we finally got a response on Aug 25, but it's a rejection under Guideline 3.1.1 that we believe misreads our app. The reviewer flagged our business/organization account registration screen, stating: "The app includes an account registration feature for businesses and organizations, which is considered access to external mechanisms for purchases or subscriptions to be used in the app," and asked us to remove business/org registration entirely. The screenshot they attached shows only our Company Registration screen, just a work email and password field with a "Create Account" button. There's no purchase flow, pricing, or payment mechanism on that screen or reachable from it. Our app is a B2B marketplace connecting NYS-licensed security agencies with security guards for real, in-person shift coverage. Billing (a subscription for platform access) happens separately, later, and only for agencies that choose to subscribe, similar to how any B2B SaaS tool (Slack, Notion, etc.) lets a business create a free account before selecting a paid tier, without that account-creation step needing to go through in-app purchase. Has anyone dealt with a similar 3.1.1 rejection for a B2B/enterprise account registration flow, where the reviewer seems to conflate account creation with an external purchase mechanism? Curious whether this is a known pattern and what resolved it, a specific citation to reference, particular wording in App Review notes, or an actual call with Apple that got it unstuck. Is there anything else we should try, or can someone from the App Review team take a look at this case? Happy to provide any additional information needed — we just want to understand what's needed to move forward. Apple ID: 6799377443 Submission ID: 1522a8de-defd-44f8-92e8-9edbb0d85c28 Appreciate any insight.

App: Linkbee (Apple ID 6798913756) Submission ID: 745fa6e5-ba33-4687-a4a3-7bb5b12005a3 Resubmitted: August 17, 2026 Our submission has been in Waiting for Review for eight days. Background: on August 14 we received a Guideline 5.6 notice. We replied in Resolution Center on August 16 explaining the cause and the fix, and resubmitted on August 17 with a corrected build. We have had no response to that reply. Is anything further required from us, or is the submission held for additional review? Happy to provide any verification needed.

Hello, I apologise for posting here. I know this forum is not a support channel, and I would not have posted if I had another way to reach App Review. Apple ID: 6759336435 Submission ID: 59a73f4a-e83b-4fa4-96dc-4c4b6a0ebcc4 Version reviewed: 1.0 (3) In review since: August 10, 2026 Rejection received: August 20, 2026 Our first submission was rejected under Guideline 4.3(a), on the basis that the app shares a similar binary, metadata or concept with apps previously submitted by a terminated Apple Developer Program account. We have no connection to any terminated developer account. RocketIO is not related to any other app, including the other apps on our own account. It is a separate product that we have been designing and writing for several years, on a different technical foundation: 114,817 lines of Dart across 139 files in Flutter, plus the Swift we wrote for the iOS tunnel host and the Network Extension, 187 tests, and 32 fully translated languages. We believe the binary match is a false positive. RocketIO statically links a publicly available open-source proxy core, as every app in this category does. That core is the largest part of the compiled binary, so any two apps linking the same open-source library will share a large amount of identical compiled code no matter how different their own source is — exactly as apps linking OpenVPN or WireGuard do. We cannot remove it, because it is the reason the app exists. RocketIO is also a bring-your-own-configuration client rather than a VPN service. It ships with an empty server list and does nothing until the user supplies a configuration for infrastructure they already own. We operate no servers, sell no subscriptions and carry no traffic. Among the protocols we have implemented are several that very few clients support on any platform, including DNSTT (DNS tunnelling), AnyTLS, ShadowQUIC, Mieru and Juicity, some of them added only recently. We replied in Resolution Center with all of this in detail, and asked which app or account the similarity was matched against, so that we could respond to the specific finding rather than guess. We are still waiting for a response. We have deliberately not resubmitted. We did not want to place another submission in the queue while this conversation is open, and we did not want to send back something that could reasonably be read as unchanged. We have been waiting since August 10, and we will be honest that it has been a difficult wait. We put years of work into this app and we have users who are looking forward to it, and at the moment we cannot tell them anything, because we do not know what specifically we are being asked to change. Could someone from App Review please reply to us there? We are glad to provide our source repository and its full commit history, to take a call at any time convenient to you in English, and to demonstrate the app live. Thank you for your time.

Hi all, My app has been stuck in the "Waiting for Review" status since August 13 (US Time), and today is August 23. It has been 10 days without any status updates or messages from the App Review team. App ID: 6800282515 Submission Date: Aug 13, 2026 Developer Support Request Submitted: Aug 19 (No response yet) Expedited Review Requested: Aug 20 (No response yet) Current Status: Waiting for Review Since both support inquiries and expedited requests haven't received a reply after several days, I am concerned there might be an internal system hold or communication breakdown regarding this submission. Could someone from Apple please look into this or advise if any additional documentation/action is needed from my side? Thanks for your help!

I specifically requested a Developer Support callback for an active App Review rejection, not general Apple Support. My issue wasn’t with my Apple ID, billing, or my account—it was about an App Review clarification that appears to be stuck in a loop. The rejection itself wasn’t because of a crash or missing functionality. It was another request for information that I had already provided in previous App Review responses. It genuinely felt like the reviewer was only looking at the latest message instead of the full review history and previous attachments. To try to resolve it, I called Developer Support and selected the App Review option. I waited on hold for over 3 hours. When someone finally answered, instead of helping with App Review or escalating the case, they transferred me to Apple Account Support. The representative there immediately told me they couldn’t help because my issue had nothing to do with Apple accounts, and they also couldn’t transfer me back to the App Review queue. So after waiting more than three hours, I was effectively back at square one and had to start over. Has anyone else experienced: Reviewers seemingly not seeing previous App Review responses or attachments? Being stuck in repeated clarification requests for information you’ve already provided? Being transferred from Developer Support to the wrong department after waiting hours? I’m trying to figure out whether this is an isolated incident or whether the App Review support process has been breaking down recently.

Hello Apple Developer Team, I’m reaching out regarding a significant delay with the App Review of my new app, Alsaqar. The app has been stuck in “Waiting for Review” for several days, even though I have already completed all the actions requested by the App Review team. App Review previously contacted me under: Guideline 2.1 – Information Needed – New App Submission I provided all the requested information, including: A screen recording of the app A physical-device test recording Demo account credentials Tested device and iOS version Detailed information about the app's purpose and functionality Information about external services and SDKs Details regarding the live auction, bidding, and in-app chat functionality The submission is still showing “Waiting for Review” and has not moved to “In Review”. For reference: Apple ID: 6802453859 Submission ID: bc2f6a16-72cd-4c13-91a0-6622596e8a60 Support Case ID: 20000143841837 I have also contacted Apple Developer Support regarding this issue and received confirmation that my support request was received, but I have not received any further response or update. This delay is significantly affecting me and my business, as the application is ready for review and I have already completed everything requested by the App Review team. Could someone from Apple please check whether there is any issue with my submission or whether it is correctly queued for App Review? I would greatly appreciate it if the submission could be reviewed or escalated to the appropriate team. Thank you for your time and assistance.

Our app Blobber (id 6791237124) launched on the App Store on August 2. Version 1.0 shipped with a critical bug: the Attention report — a core feature on the app's main screen — stays locked showing "Screen Time needed" even after the user grants Screen Time permission. Every new download is affected and there is no workaround in 1.0. We submitted the fix (1.0.1, a single-bug release) on August 5. Six days later it is still "Waiting for Review". Version 1.0 was consistently reviewed within 24–48 hours in July, so this delay is unusual for our account, and it lands squarely in our launch window while every new user hits a broken core feature. Is there anything beyond the standard expedited review request we can do to get movement on this? Has anyone else seen multi-day "Waiting for Review" queues recently?

I’ve been waiting over a week regarding an issue that had already been resolved previously, but for which I never received any further clarification. I’ve sent multiple messages to the App Review team, but haven’t received any response. These waiting times are honestly insane. Has anyone else experienced this?